The present invention relates generally to software products for message bridging, and more specifically, to a system and method for integrating software products having different event message input and output formats.
During the course of day-to-day business transactions within enterprises, e.g., credit card companies, brokerage houses, and airlines, immense amounts of data are continually recorded. Such entities typically employ enterprise computing, wherein an enterprise may comprise a large number of computers of varying type (e.g. mainframes, minicomputers, microcomputers and workstations), with multiple hosts, running on multiple platforms of varying type. This may be due to internal or external reorganizations or mergers of various entities or departments, each with different computing needs, and thus, a variety of hardware and software to fulfill those needs. On a computer scale, enterprises may be as dynamic as the human population.
One exemplary enterprise component is a storage manager. In an enterprise, ongoing backup of enterprise-wide data must be continuously performed, so that, in the event the machine storing the original copy of the data fails or is inaccessible, a backup copy of the data may be retrieved. One exemplary archival system for making and restoring such backups is the Tivoli™ Storage Manager (TSM). Such an archival system may provide a guarantee for enterprises that their valuable data, which is often an enterprise's largest asset, or software, may be restored from an archive in the event the original data becomes unavailable.
To manage, monitor and/or control the activities of the various enterprise components, an enterprise console, e.g. Tivoli™ Enterprise Console (T/EC) is employed. The enterprise console uses a plurality of agents or “spies” to gather information about the activities of the various enterprise components. Such information is sent to the enterprise console when problems or faults occur. The enterprise console provides this information to an administrator or an information technology resource manager at a central location, so that he or she may efficiently deploy information technology or consulting services. For example, if a system in a particular department crashes, the administrator can send a consultant to that department immediately to resolve the problem. As another example, if a machine runs out of space, the administrator, on the fly, can allocate some more space for that machine. The enterprise console thus allows the administrator to remain in one physical location to stay apprised of events taking place within the enterprise at any number of physical locations.
Within a single enterprise, the enterprise console and various enterprise components have often been developed independently of one another and, additionally, may be mature products. For example, the T/EC and TSM were both developed independently by different developers working for different companies and have each undergone a number of revisions. Today, the T/EC and TSM are owned and supported by the same company due to corporate acquisitions, yet there is no standard for exchanging event messages between the two products. Beyond this specific example, similar situations exist with respect to software and hardware components within many enterprises as well as outside the enterprise context.
As among such various components, each component, e.g., a backup archive product, an enterprise control, a database application, and a web host, has different requirements and needs for sending and receiving event messages to and from other components. Additionally, each component may have different formats for the event messages it is able to send and receive, without any single standard in existence.
Therefore, a translation means must be employed for allowing various components to communicate effectively with one another. One translation method known in the art is the use of a dedicated hardware device for receiving, translating, and sending event messages, e.g., between a Unix machine and a mainframe, between Unix and a Windows NT™ machine, between a mainframe and a Windows NT™ machine, or other translations between operating systems. However, many such hardware devices are unable to translate event messages between two different types of software, since what needs to be translated is how the information is presented, (e.g., how the information is ordered in ASCII), and not how the information is stored, (e.g., as binary data).
In the networking field, translations are routinely performed, at various levels within layers of a communication protocol, e.g., as between various layers of TCP/IP, or between a TCP/IP layer and a NetBEUI. layer. However, translations are not performed at the application-to-application layer in this context.
Sending messages from an enterprise storage management product to an enterprise event receiver has previously been problematic. Known solutions include the use of logfile adapters or reverse engineering of the API for the event receiver. Use of a logfile adapter is disadvantageous, as it presents issues with scalability (number of processable messages) and resource issues, and a priori knowledge of the messages is required. Reverse engineering the API is disadvantageous, as it presents synchronization and resource issues, since every time the API is updated, all of the reverse engineering effort must be done again. There also is no guarantee that the reverse engineering efforts will be successful after the API has been modified.